Important: Some of the features may not be available in this release. Kindly contact your local Cisco representative for more information on supported features.IPCF acts as a PCRF functions supplemented with usage monitoring capability that enables policies around data consumption. IPCF interfaces with the PCEF over standard Gx/Gxa/Rx interface for policy management and optionally Volume Reporting over standard Gx (VRoGx) interface for getting the usage of IP Connectivity Access Network (IP-CAN) sessions.
|
•
|
|
•
|
|
•
|
The SSC interacts with IPCF over Sp (a standard Sh protocol based) interface for given functionality. SSC also supports a proprietary EN interface, which is based on XML-RPC protocol, to receive event notification data from IPCF.
For more information on SSC function and supported interfaces, refer Subscriber Service Controller Installation and Administration Guide.
For more information on PPT function and supported interfaces, refer Policy Provisioning Tool Installation and Administration Guide.
The IPCF is a licensed Cisco product. Separate session and feature licenses may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
The IPCF service runs on a Cisco® ASR 5x00 chassis running StarOS Rel. 10 or later. The chassis can be configured with a variety of components to meet specific network deployment requirements. For additional information, refer to the Installation Guide for the chassis and/or contact your Cisco account representative.
In standalone deployment multiple PCEF (GGSN/PDSN/P-GW) connects to a single IPCF through Gx interface and served by the PCC elements through IPCF.
In co-located deployment IPCF sits with PCEF on the same chassis. It interacts with PCEF through internal connection matching Gx reference and connects to other PCC elements over various interfaces.
|
•
|
Gx: This reference is an interface between IPCF and PCEF. It is a Diameter protocol-based interface over which the IPCF communicates with a PCEF for the provisioning of charging rules. The charging rules are based on the dynamic analysis of flows used for a 3GPP or Non-3GPP IP-CAN subscriber session.
|
The Gx reference point enables an IPCF to have dynamic control over the policy and charging control behavior at a PCEF. The Gx reference supports the following functions:
|
•
|
Termination of Gx session (corresponding to an IP-CAN session) by PCEF or IPCF
|
Important: The IPCF decision to termination an Gx session is based on situation like removal of a UE subscription etc.One or more Gx interfaces can be configured per system context.
To provide accessibility to PDSN as PCEF in CDMA/HRPD access network for 3GPP IP-CAN type session, Gx interface uses NAI and IMSI as subscriber Id and ESN and MEID for user equipment information.
|
•
|
Gxa: This reference is an interface between IPCF and the Bearer Binding and Event Reporting Function (BBERF) at AN-GW. It is a Diameter protocol-based interface and enables an IPCF to have dynamic control over the BBERF behavior at AN-GW.
|
The Gxa reference point enables the signalling of QoS control decisions and it supports the following functions:
|
•
|
One or more Gxa interfaces can be configured per system context.
|
•
|
Sp: This is a Diameter-based interface resides between Cisco IPCF and SSC. It is based on standard Sh interface.
|
Only 1 Sp interface can be configured per system context.
|
•
|
Event Notification Interface (EN): The EN interface supports uni-directional transfer of events from IPCF to SSC. This is an XML-RPC protocol based proprietary interface to send outbound event notifications to the SSC and forward these events to an event application module to generate mail/SMS notification to user/subscriber.
|
Only 1 EN interfaces can be configured per system context.
|
•
|
Rx: This interface is the reference point between the Application Function (AF); i.e. IMS and the IPCF. This is a Diameter based interface.
|
The Rx reference point enables transport of application level session information from AF to IPCF. Such information includes:
One or more Rx interfaces can be configured per system context.
|
•
|
CORBA-based Interface: IPCF supports the North-bound CORBA interface support for PPT and WEM management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems. It gives the ability to operator to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.
|
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
Important: System management functionality is enabled for console-based access by default. For GUI-based management support, refer Web Element Management System.
Important: For more information on command line interface based management, refer Command Line Interface Reference.|
•
|
System: Provides system-level statistics
|
|
•
|
Card: Provides card-level statistics
|
|
•
|
Port: Provides port-level statistics
|
|
•
|
PCC-AF: Provides PCC Application Function related statistics
|
|
•
|
PCC-Policy: Provides PCC Policy related statistics
|
|
•
|
PCC-Service: Provides statistics collected for PCC service on a chassis endpoint in PCC service
|
|
•
|
PCC-Sp-Endpoint: Provides statistics collected at Sp interface endpoint in PCC service
|
|
•
|
Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.
|
|
•
|
Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.
|
|
•
|
SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values.
|
|
•
|
Logs: The system provides a facility called threshold for which active and event logs can be generated. As with other system facilities, logs are generated Log messages pertaining to the condition of a monitored value are generated with a severity level of WARNING.
|
|
•
|
Alarm System: High threshold alarms generated within the specified polling interval are considered “outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding” alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.
|
Important: For more information on threshold crossing alert configuration, refer Thresholding Configuration Guide.
Important: Some of the following features may require the purchase of an additional license to implement the functionality with the IPCF node.|
•
|
Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby packet processing card. In this mode, recovery is performed by using the mirrored “standby-mode” session manager task(s) running on active packet processing cards. The “standby-mode” task is renamed, made active, and is then populated using information from other tasks such as AAA manager.
|
|
•
|
Full packet processing card recovery mode: Used when a packet processing card hardware failure occurs, or when a packet processing card migration failure happens. In this mode, the standby packet processing card is made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet processing card perform session recovery.
|
Important: For more information on this feature, refer Session Recovery chapter in System Administration Guide.
Important: For more information on WEM support, refer WEM Installation and Administration Guide.Every time a new IP-CAN session is established through PCEF’s Gx interaction with IPCF, it queries SSC specifically to get subscriber’s profile as well as the usage details during the current billing cycle. After receiving the subscriber profile, it forward the same to PCEF. For remaining duration of the session the subscriber policy profile remains cached with IPCF and no query performed over Sp.
Moreover, on any changes to the profile or to the subscription plan, SSC notifies IPCF over Sp interface, that is managing the session for the subscriber getting affected. IPCF ensures that the local repository has the most updated profile record for the subscriber at all times.
In the case IPCF is also tracking the usage for deriving policy decision on the basis of same, it would appoint itself for pre-paid usage monitoring through Gx for usage control.
In the case where IPCF also performs usage monitoring via VRoGx interface, in addition to the session state triggers, additionally the usage can be monitored and operator can define various policy triggers around the usage thresholds for a session or even group of sessions. In the cases where usage is to be monitored across multiple sessions and PCEFs (from same or group of subscribers); e.g. for group policies, IPCF combined with SSC’s usage monitor module, enable the PCC system to track and trigger appropriate treatments required for the multiple sessions. IPCF communicates with SSC over Sp interface which enables a synchronous fetch and update related to usage as well as asynchronous notifications from SSC to the IPCF, handling the sessions which may get impacted due to consumption reported by a session being tracked at a different IPCF.
At this stage the PCEF initiates a new Gx session by sending a Diameter CCR to the IPCF and set the CC-Request-Type AVP to INITIAL_REQUEST.
|
•
|
|
•
|
In this procedure the IPCF associates the Gx session for the new IP-CAN session with the corresponding Gateway Control Session and maintains the aligned set of PCC and QoS rules in the PCEF as applicable for the case.
|
4.
|
Optional. If the IPCF needs subscription-related information and does not have it, the IPCF sends a Profile Request to the SSC in order to receive the information.
|
If online charging is applicable then the PCEF requests credit information from the OCS over the Gy interface.
This procedure is applicable for establishment of Rx connection between IPCF and AF (IMS) in core network.
The following figure and the text that follows describe the message flow for an Rx connection establishment procedure.
|
2.
|
|
4.
|
Optional. If the IPCF needs subscription-related information and does not have it, the IPCF sends a Profile Request to the SSC in order to receive the information.
|
|
9.
|
When Gxa does not apply for the IP-CAN session, IP-CAN bearer signalling is executed separately for each IP-CAN bearer under the following conditions:
|
The IPCF complies with the following standards for UTRAN/E-UTRAN/cdma2000-1x/HRPD networks services.
|
•
|
|
•
|
|
•
|
